1. Field of the Invention
This invention relates to the field of management information service (MIS) access mechanisms. In particular, the invention provides a JAVA application programmer with an interface to a MIS, such as the Solstice.TM. Enterprise Manager.TM. from Sun Microsystems Inc., to access records in the MIS.
2. Background
Object-oriented programming (OOP) languages associate an object's data with programmed-methods for operating on that object's data. Usually, OOP objects are instantiated in a heap memory area and are based on classes that reference the programmed-methods for the OOP object. Instantiated OOP objects contain data (in instance variables) specific to that particular instantiated OOP object. Conceptually, an OOP object contains object-related information (such as the number of instance variables in the object), the instance variables, and addresses of programmed-methods that access and/or manipulate the contents of the instance variables in the object. However, because objects often share programmed-methods and object-related information, this shared information is usually extracted into a class. Thus, the instantiated object simply contains its instance variables and a pointer to its class.
Smalltalk, Java and C++ are examples of OOP languages. Smalltalk was developed in the Learning Research Group at Xerox's Palo Alto Research Center (PARC) in the early 1970s. C++ was developed by Bjarne Stroustrup at the AT&T Bell Laboratories in 1983 as an extension of the C programming language. Java is an OOP language with elements from C and C++ and includes highly tuned libraries for the internet environment. It was developed at Sun Microsystems and released in 1995.
Further information about OOP concepts may be found in Not Just Java by Peter van der Linden, Sun Microsystems Press/Prentice Hall PTR Corp., Upper Saddle River, N.J., (1997), ISBN 0-13-864638-4, pages 136-149.
A client/server computing environment allows a client computer to use a service or resource provided by a server computer. Generally many clients use the server computer. The client/server environment provides advantages well known in the art and described in Not Just Java at page 199. With the advent of programming environments that are independent of the computer used to execute them (for example, programming environments that include the Java Virtual Machine), client applications are being developed that execute on a variety of different computers. Because the executable code for these applications is independent of the computer architecture and operating system that execute the code, only one compilation of the executable code need be created. This compilation of the executable code can be transferred from storage on a server, over the network, to a client where the code is executed. Sometimes the client and server portions of an application execute on the same computer.
A "thin-client" is a networked client computer that does not have permanent local storage. Thus, the storage service is provided by a server computer termed a "thick-" or "fat-"server. Thin-clients read Java applications stored on the fat-server and locally execute them. These applications can, in turn, access data from the fat-server or other sources on the Internet. The thin-client/thick-server environment is described in Not Just Java at pages 207-218.
As previously mentioned, Java is an object-oriented programming language. Thus, it is useful to transport objects between the client and server. It is also advantageous to invoke an object's method that resides on one computer by a program executing on another computer. Java generally uses the remote method invocation (RMI) interface to provide this capability. The RMI interface is described in Core Java, by Cornell and Horstmann, 2nd edition, ISBN 0-13-596891-7, .COPYRGT. 1997 Sun Microsystems, Inc. at pages 643-681. Other interfaces exist (such as the CORBA standard) that provide similar functionality.
One difficulty with remote method invocation interfaces is that the application programmer must explicitly obtain a reference to a remote object before invoking that object's programmed-methods. This additional complexity increases the difficulty involved to create a networked application. In addition, the object's programmed-methods are either executed on the client or on the server dependent on the location of the object. Thus, simple programmed-methods, such as obtaining the value of an object's data, are high overhead operations if the object is located on the server because the client must cause the server to execute the programmed-method that returns the value. This value is then returned across the network to the client. These overheads impact the performance of the application on the thin-client. It would be advantageous to provide an object that extends across the client/server interface and that has the capability to automatically execute one of its programmed-methods on the client and another of its programmed-methods on the server. One aspect of the invention provides this capability.
Another problem with client-server systems, such as the previously described thin-client/fat-server system, is that the server portion of the system generally must invoke operations on an existing service--one that was not necessarily implemented to take advantage of modern computing environment features such as a multi-thread capability. Thus, the programmer generally limits the implementation of an application to the programming techniques allowed by the existing service. Because many existing server applications do not support thread-safe APIs, multiple client threads (either in the same server, or extending across multiple servers, or both) must synchronize access to the service so the client application can be written using the modern programming techniques. Thus, when the service is upgraded to use the new methodology, the existing client programs will not need to be modified to use the new capabilities of the service. In addition, many APIs are written in a programming language other than the language used to write an application. It is expensive to convert an API written in one language to another language. Thus it is advantageous to provide an API written in the new language that invokes the methods used by the corresponding API written in the original language. Threads are briefly discussed in Not Just Java at pages 149-156.
A network management information service is an example of a service that can be provided to a client by a server. Such a service, like the Solstice.TM. Enterprise Manager.TM. from Sun Microsystems Inc., gathers information about network devices, stores this information in a management information service (MIS), and provides this information to other applications. Monitoring this information in a thin-client/fat-server environment would allow a user or network administrator to monitor network from inexpensive thin-clients or from a Java enabled web browser. Such a network management application on a client must be able to request information about the network devices that are relevant to the network administrator. Such an application must also receive notification that a relevant event has occurred in the MIS regarding those devices. Thus, it would be advantageous to provide a technique that serializes clients' access to a shared service and that distributes events generated by the service to the clients that have registered to receive the events.
Yet another problem with client-server systems is that of the client performing operations on their server's MIS. In particular, sending large numbers of data records from a MIS system from the server to the client requires significant network bandwidth if the client and server reside on different computer systems. Also, if the client is a thin-client it may not have sufficient resources to timely process or store the data records. Thus, it would be advantageous for the server to provide those services that require extensive computational and I/O processing to the client through an API.